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Abstract 


Here we demonstrate the practicality of providing web servers on the HSMM-Mesh. The first example 
shows a standalone server connected to its own Mesh node. In the second example, a Mesh node is 
added to an existing network that has web servers on its private and perimeter sub-networks. 
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Summary 


Emergency communication is one of the main purposes of Amateur Radio. This has traditionally been 
provided by voice and low speed data such as Morse Code. High Speed Multimedia (HSMM) is a 
recent initiative to use Amateur Radio spectrum for high bandwidth data. 


The HSMM-Mesh adapts consumer wireless networking equipment originally licensed under Part 15 of 
the Federal Communications Commission (FCC) Rules to Amateur Radio use regulated by part 97. 


The Mesh is in its early stages of growth. It currently exists as groups of Mesh nodes (or even a single 
Mesh node) that cover small areas. Some of these Meshes are connected to each other through Internet 
tunnels. HSMM-Mesh.org is actively developing the Mesh. 


While all nodes on the Mesh are part of the infrastructure, some exist primarily to provide client access 
or services to the Mesh. This paper describes one effort to provide web servers to the Mesh. It is hoped 
that the ideas presented here can be adapted to networks at sites served by Amateur Radio Operators. 


Portable Web Server 


A portable web server can be added to the Mesh using a portable computer and a mesh node. This was 
demonstrated by connecting a netbook to Mesh node N7XSD-102. 


Node N7XSD-102 is a Linksys WRT54GL with HSMM-Mesh firmware version 0.4.3 installed. 


The portable computer, Zoe, is a simple Ubuntu Linux netbook with the addition of an Apache web 
server. The wired Ethernet interface, eth0O was already configured to use DHCP and the wireless 
interface was disabled. 


After Zoe was connected to a LAN port on N7XSD-102, a few configuration changes were required in 
“Port Forwarding, DHCP, and Services” of “Setup”. First, a DHCP address reservation for Zoe was 
added. Second, Zoe was chosen as the DMZ server. Third, portable-web was added as an 
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advertised service. A screen shot is shown in Illustration 1. 


After the changes were saved, the web site http: //N7XSD-102/ was available on the Mesh. 


Existing Office Network 


The home office network used consisted of a perimeter sub-network connected to two firewalls. The 


first, 


fw0O, connected the perimeter sub-network to a private sub-network with servers and workstations 


running both GNU/Linux and Mac OS X as well as wireless access points. The second, fw1, connected 
the perimeter sub-network to the Internet via WiMAX. All of these nodes used “stock” firmware and 


operating systems. 


Firewall fw1 provided DHCP and DNS for nodes connected to the perimeter network. Wash, a Debian 
GNU/Linux server, provided DHCP and DNS on the private network and also file services. Jayne, a 
Debian GNU/Linux server, hosted a public facing web server from the perimeter sub-network while 
Mal, an OS X desktop system, was used as a web server on the private sub-network. This network is 


shown in Ilustration 2. 


Both firewalls were capable of Network Address Translation (NAT). The perimeter sub-network used IP 
addresses in the 192.168.15.0/24 network and the private sub-network used 192.168.31.0/24 
addresses. Both sub-networks had addresses outside the DHCP scope that can be used for static 


assignments. Internet connections from ports 811 through 827 were forwarded by 


same ports were then forwarded by fw0 to Mal. Ports 889 to 899 were forwarded by fw1 to Jayne. 


fwl to fw0. The 


IP network 10.0.0.0/8 was not being used. This was an important consideration, since “ten” is 
always used by the Mesh for its wireless interface. 
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N7XSD-102 setup 


N7XSD-102 setup 
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Port Forwarding Advertised Services 
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DHCP Address Reservations 
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Illustration 1: N7XSD-102 Port Forwarding 


New HSMM-Mesh Node 


Mesh node N7XSD-101 was established to give the web servers Mesh connectivity. No effort was 
made to give users of the home office network access to servers on the Mesh, nor was anything done to 
prevent users from accessing the Mesh. 


Before being placed into the existing network, a Linksys WRT54GL was connected to a laptop computer 
with an Ethernet cable. All the laptop needed was an Ethernet connection, a web browser, and the 
current HSMM-Mesh firmware. It was already configured as a DHCP client (this is common for laptop 
computers). 


Instructions from HSMM-Mesh.org were used for the original configuration. DHCP was then disabled 
from the LAN ports and the mesh node assigned an address of 192.158.15.2. This address was 
outside the DHCP scope on the existing network. A screen shot of the basic setup is shown in 
Illustration 3. 


Node N7XSD-101 was then disconnected from the laptop and connected to the perimeter switch. The 
remaining LAN ports were then also available for nodes on the perimeter network. The WAN port was 
not needed. 


Internet 
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Illustration 2: Network 
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Network Routing 


HSMM-Mesh uses IP addresses in the 10.0.0.0/8 network. A static route was added to fw0. 
Without this static route, packets intended for the 10.0.0.0/8 network were being routed to fw1, the 
default gateway on the perimeter sub-network. 


DNS Name Server 
Changes were made to the existing DNS servers. 


DNS zones mesh and 10.in-addr.arpa are used by HSMM-Mesh. The BIND configuration on 
Wash was changed to provide name resolution in these zones to the perimeter and private sub-networks. 
This was done with condition forwarding. 


zone "mesh" { 

forward only; 

forwarders { 

192.168.15.2; 

} 

type forward; 

}; 

zone "10.in-addr.arpa" { 

forward only; 

forwarders { 
192.168.15.2; 

}; 

type forward; 


N7XSD-101 setup 
N7XSD-101 setup 
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Node Type | Mesh Node +) Verify Password 
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SSID HSMM-MESH DHCP Server © 
Mode Ad-Hoc : DHCP Start [130 | Mesh Gateway (© 
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Active Settings 
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Illustration 3: N7XSD-101 Basic Setup 
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Node N7XSD-101 was also added to the zone file for n7xsd.us. 


meshl0l1-lan IN A 192-1685 1552 
meshl0Ol-mesh IN A LO. Xw¥ 216 
meshl01 IN  CNAMI meshl0l1-lan 


Gl Gl 


N7XSD-101 IN CNAMI meshl01-lan 


The only record that was really important was the address record for 192.168.15.2. The additional 
records were added to fit in with local naming conventions. Also note that N7XSD-101.n7xsd.us 
and N7XSD-101.austin.tx.us.mesh resolve to two different addresses. 


Mesh node N7XSD-101's web interface could then be reached at http: //N7XSD-101:8080/ from the 
perimeter and private sub-networks. 


Existing Web Servers 


Jayne was an Ubuntu Linux server with an Apache 2 web server. This server was connected to the 
perimeter sub-network and had IP address 192.168.15.4. Apache listened on TCP ports 80 and 898 
and did not have any virtual servers. All content on this server was appropriate for Amateur Radio. That 
is, none of the content was forbidden by Part 97 of the FCC rules. 


Firewall fw1 did not provide a route to network 10.0.0.0/8. The command route add -net 
10.0.0.0 netmask 255.0.0.0 gw 192.168.15.129 dev eth0O was added to Jayne's 
startup to provide routing to the Mesh. 


Mesh node N7XSD-101 was changed to direct port 898 to 192.168.15.4 and port 818 to 
192.168.15.2. Firewall fwO would then forward port 818 to Mal. Port forwarding and advertised 


N7XSD-101 setup 
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Current DHCP Leases 
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Illustration 4: N7XSD-101 Port Forwarding 
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services on the Mesh node are shown in Illustration 4. 


Mal was a Mac OS X Lion desktop workstation on the private sub-network with IP address 
192.168.31.115. Anew virtual server was created to serve specific content to the Mesh on port 
818. The virtual host definition is given below. 


<VirtualHost *:818> 
DocumentRoot "/Library/WebServer/Documents/hsmm-mesh" 
ServerAlias n7/xsd-101 n7xsd-101.austin.tx.us.mesh 
ServerName hsmm-mesh.n7xsd.us 

</VirtualHost> 


File locations vary between installations. Apache virtual hosts are described on the Apache web site. 


Web sites http: //N7XSD-101:898/ and http: //N7XSD-101:818/ were then both available from the 
Mesh. 


Conclusion 


The HSMM-Mesh can provide network connectivity to areas impacted by natural or man made disaster. 
Nodes on the Mesh can provide web and other services. 


What services are most valuable to first responders using the Mesh remains an open question. One 
possibility is to extend existing tools (i. e. WebEOC) used by emergency management agencies to the 
field. Another option is to provide a complete package such as Sahana or Tickets CAD on the mesh. 
This questions and more should be investigated while the HSMM-Mesh grows into a robust 
infrastructure. 
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